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REMARKS 

Claims 1, 63 and 68 have been amended. Claims 1, 57-69, and 71-78 are pending in 
this patent application. Reconsideration of the rejections in view of the remarks below is 
requested. 

Claims 1, 57-61, 63-69, 71, 73, 74 and 76-78 stand rejected under 35 U.S.C. § 102(e) 
as being anticipated by United States patent no. 5,815,657 to Williams et al. ("Williams"). 
The rejection is respectfully traversed. 

: Applicant respectfully submits that the cited portions of Williams fail to disclose, 
inter alia, obtaining electronic signals representing a request for transactional financial 
assurance with respect to electronic infrastructure used in or with a transaction involving the 
subscriber, the transactional financial assurance being other than a digital signature of the 
electronic infrastructure or the electronic signals representing subscriber assurance, and 
determining whether to provide the requested transactional financial assurance based on at 
least the subscriber assurance, as recited in claim 1. 

For example, the cited portions of Williams appear to be silent as to transactional 
financial assurance with respect to electronic infrastructure used in or with a transaction, the 
transactional financial assurance being other than a digital signature of the electronic 
infrastructure or the electronic signals representing subscriber assurance. As non-limiting 
examples, the cited portions of Williams appear to be silent as to providing assurance 
regarding the authenticity of an electronic certificate, assurance regarding the accuracy of an 
electronic certificate, or assurance regarding the validity of an electronic certificate. As 
discussed previously, the system of Williams appears merely to facilitate payment between a 
consumer and a merchant. 

The Office Action, at page 3, and the Advisory Action argue that "[i]n Williams at 
col. 11 lines 31-38, the certificates utilized by consumers in transactions are taught as X.500 
type certificates. As such, these certificates will contain a digital signature utilized in the 
process of verifying the certificate taught at col. 13 line 40 through col. 14 line 23. This reads 
on the Applicant's feature of assurance of the validity of the certificate." Applicant 
respectfully disagrees. The X.500 type certificate of a consumer in the transactions referred to 
in the cited portions of Williams is an embodiment of the "subscriber assurance" recited in 
the claim 1. The X.500 type certificate referred to there is essentially the same as the X.509 
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type certificate referred to in the background of Applicant's application. See, e.g., page 2, line 
20 to page 3, line 8 of Applicant's specification ("Digital signature certificates (sometimes 
also called public key certificates or simply certificates) meet this need. These certificates, are 
generally issued by trusted third parties known as certification authorities (CAs) and they 
certify (1) that the issuing certification authority has identified the subject of the certificate 
(often according to specifications delineated in a certification practice statement), and (2) that 
a specified public key (in the certificate) corresponds to the a private key held by the subject 
of the certificate. A structure for public-key certificates is included in the X.5Q9 standard 
cited earlier."). 

The recited transactional financial assurance is not the consumer X.500 type 
certificate (or the digital signature contained therein) in the cited portions of Williams. To be 
certain, claim 1 recites that the transactional financial assurance is other than a digital . 
signature of the electronic infrastructure or the electronic signals representing subscriber 
assurance. Indeed, it is precisely the consumer X.500 type certificates that suffer from 
deficiencies as discovered by Applicant and addressed by one or more embodiments of the 
invention. See, e.g., page 6, line 13 to page 8, line 21 of Applicant's specification. 

The Office Action also indicates that Williams teaches that "both merchant and 
consumer certificates are sent for verification as part of a request message." However, claim 
1 recites a request for transactional financial assurance with respect to electronic 
infrastructure used in or with a transaction involving the subscriber. So, even if arguendo the 
recited transactional financial assurance is the merchant and/or consumer certificates in 
Williams (which Applicant contends they are not at least for the reasons presented herein), 
then respectfully it doesn't make sense that they would be "part of a request message". Rather 
they would be the desired product of a request for them. 

The Office Action also refers to Figure 5 and col. 13, line 40 to col. 14, line 23 of 
Williams as allegedly disclosing obtaining electronic signals representing a request for 
transactional financial assurance with respect to electronic infrastructure used in or with a 
transaction involving the subscriber. For example, page 4 of the Office Action argues that 
Williams discloses at "(col. 13 line 40 through col. 14 line 23: the Payment Manager receives 
the request for transactional assurance (i.e., authorization to pay or payment) from the 
merchant, and receives certificate information from the user (user's wallet manager))". Thus, 
those cited portions of Williams appear merely to disclose one or more certificates used in the 
process of completing a payment request. Thus, while the cited portions of Williams might 
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disclose completing a payment request based on a certificate, the cited portions of Williams 
do not appear to provide, for example, any financial assurance with respect to a certificate (or 
with respect to some other electronic infrastructure used in or with a transaction involving the 
subscriber). The described certificates, and their verification mechanisms if any, in the 
Williams system may be entirely fraudulent. There appears to be no discussion of, for' 
example, provision of a financial assurance with respect to any of those certificates (or with 
respect to some other electronic infrastructure used in or with a transaction involving the 
subscriber). As noted in Applicant's specification, the conventional certificate system 
discussed in Williams has various shortcomings and leaves, for example, someone relying on 
a certificate vulnerable. See, e.g., pages 6-8 of Applicant's specification. The present claimed 
invention provides a mechanism to provide assurance regarding electronic infrastructure, 
such as a certificate, used in or with a transaction involving the subscriber. 

Claims 57-61 and 76 depend from claim 1 and are, therefore, patentable for at least 
the same reasons provided above related to claim 1, and for the additional features recited 
therein. 

For similar reasons as provided above, Applicant respectfully submits that the cited 
portions of Williams fail to disclose a computer program product, embodied in a computer- 
readable media, comprising instructions for causing a computer to effect a method of 
managing reliance in an electronic transaction system as recited in claim 63. For example, 
Applicant submits that the cited portions of Williams fail to disclose causing electronic 
signals representing the reliance request message to be sent to a reliance server requesting a 
transactional financial assurance for the aspect of the transaction upon which the relying 
party intends to rely, the transactional financial assurance including transactional financial 
assurance with respect to electronic infrastructure used in or with the transaction and the 
transactional financial assurance being other than a digital signature of the electronic 
infrastructure as recited in claim 63. 

Claims 64-67 and 77 depend from claim 63 and are, therefore, patentable for at least 
the same reasons provided above related to claim 63, and for the additional features recited 
therein. 

For similar reasons as provided above, Applicant respectfully submits that the cited 
portions of Williams fail to disclose a computer program product, embodied in a computer- 
readable media, comprising instructions for causing a computer to effect a method of 
managing reliance in an electronic transaction system as recited in claim 68. For example. 
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Applicant submits that the cited portions of Williams fail to disclose determining whether to 
provide transactional financial assurance with respect to electronic infrastructure used in or 
with the transaction based on the reliance request message, the transactional financial 
assurance being other than a digital signature of the electronic infrastructure, as recited in 
claim 68. 

Claims 69, 71, 73, 74 and 78 depend from claim 68 and are, therefore, patentable for 
at least the same reasons provided above related to claim 68, and for the additional features 
recited therein. 

Because the cited portions of Williams fail to disclose the claimed subject matter of 
claims 1, 57-61, 63-69, 71, 73, 74 and 76-78, Applicant respectfully requests that the 
rejection under 35 U.S.C. §102(e) of claims 1, 57-61, 63-69, 71, 73, 74 and 76-78 based on ' 
Williams be withdrawn and the claims be allowed. 

All rejections having been addressed, it is respectfully submitted that the present 
application is in condition for allowance. If questions relating to patentability remain, the 
examiner is invited to contact the undersigned to discuss them. 

Should any fees be due, please charge them to our deposit account no. 03-3975, under 
our order no. 061047/0268225. The Commissioner for Patents is also authorized to credit any 
over payments to the above-referenced deposit account. 



July 26, 2010 
P. O. Box 10500 
McLean, VA 22102 
(703) 770-7900 




- 10- 



